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(57) ABSTRACT 

An apparatus, program product, and method utilize 
"dynamic" groups to represent collections of individuals in 
a computer environment. With a dynamic group, a group 
membership criterion and a set of member identifiers are 
associated with one another within a dynamic group data 
structure, such that the set of member identifiers identifies 
those users from a plurality of users that meet the group 
membership criterion for the dynamic group. Dynamic 
updates arc performed periodically and/or in response to 
predetermined events, such that the set of member identifiers 
for a dynamic group are updated lo reflect modifications to 
the plurality of users, and thereby maintain the identification 
of members in the dynamic group current. Dynamic group 
data structures may be utilized in connection with multiple 
networked tai^get computer environments having users that 
span multiple computer domains and/or enterprises, wherein 
the target computer environments are networked with a hub 
computer upon which is resident a database that maintains a 
dynamic group data structure. Within at least a portion of 
such target computer environments, mirrored group data 
structures are distributed and maintained, with each includ- 
ing at least a subset of member identifiers from the set of 
member identifiers associated with the dynamic group data 
structure. 

35 Claims, 8 Drawing Sheets 
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DYNAMIC GROUP GENERATION AND 
MANAGEMENT 

HELD OF THE INVENTION 

'Ihe invention is generally related to the generation and 
management of groups of individuals within a data process- 
ing environment, e.g., for use in applications such as elec- 
tronic messaging, content management, security access con- 
trol and software distribution. 

BACKGROUND OF THE INVENTION 

As computer and networking technology has advanced, 
greater numbers of individuals have been linked together via 
interconnected computer systems to permit those individuals 
to perform both individual and collaborative tasks on those 
computer systems. In addition, the growth of public net- 
works such as the Internet and the global telecommunica- 
tions infrastructure has enabled individuals from different 
organizations and enterprises, as well as individuals from 
different parts of the globe, to effectively communicate and 
collaborate with one another. 

When interacting with multiple individuals, a computer 
system typically requires some manner of identifying an 
individual, e.g., to determine where to send messages to that 
individual, to determine whether that individual is autho- 
rized to perform certain actions, etc. As a result, each 
individual that utilizes a computer system typically is asso- 
ciated with a set of data that is used by various computer 
systems to identify that individual. The data structures, 
which arc often referred to as user records, typically include 
information such as name, network address, authorizations, 
and other data about an individual that may be useful in 
performing whatever tasks a computer system is performing 
on behalf of that individual. Depending upon the degree of 
interaction between a computer system and an individual, 
the user record may contain any amount of information 
about an individual, e.g., from only nominal information to 
fairly comprehensive information. For example, in an Inter- 
net email application, as little information as an email 
address may be tracked for certain individuals. In contrast, 
for an enterprise- wide group ware application, individuals 
may be associated with information such as name, 
department, facility, email address, physical address, net- 
work address, security authorizations, telephone numbers, 
etc. 

While computers may interact with and perform tasks on 
behalf of individual users, in many instances, computers 
may be called upon to interact and/or perform tasks on 
behalf of multiple individuals. To support computer opera- 
tions that deal with multiple individuals, a number of 
computer environments support the concept of a "group," 
i.e., a logical representation of a collection of individuals. 

Groups find utility in a wide variety of computer appli- 
cations. For example, in electronic messaging applications, 
groups may be used to facilitate message distribution to 
various related individuals with common interests, common 
positions within an enterprise, etc. For example, groups may 
be defined for the members of a team or project, members 
of a particular department or level of management, members 
that work in the same facility, etc. 

Groups also find utility in applications such as security 
management, content distribution and software distribution, 
where certain types of individuals may share common 
authorities, and thus be permitted to perform certain actions 
(or use or view certain content or software) that are not 
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available to the entire set of individuals that may have access 
a particular computer system. For example, within a com- 
puter network environment, certain individuals that maintain 
and manage a computer network may be granted greater 

5 authority than other individuals to permit those "adminis- 
trators" of the network to change settings and otherwise 
configure the network to fix errors or improve its perfor- 
mance. Also, in some instances, certain software applica- 
tions or content may be restricted to viewing only by certain 

10 individuals, e.g., the members of a project or team. By 
placing all of these individuals into a common group, 
authorities may be defined for the group as a whole, which 
facilitates managing the authorities granted to various indi- 
viduals. 

15 To manage a group within a computer environment, some 
form of data structure is typically required to permit the 
individuals, or "members" of that group to be readily 
identified. Many computer environments utilize data struc- 
tures known as "records" to store the data necessary to 

20 identify the members of a group, as well as additional 
information that is pertinent to all members of the group, 
e.g., granted authorities and the like. 

Conventional groups share a common characteristic inso- 
far as such groups are enumerated, whereby the members of 
the group are required to be individually identified and 
ass(x;iated with the group. As a result members are typically 
added and removed to and from a group on a member-by- 
member basis. 

Whereas enumerated groups are adequate for use in many 
applications, in some instances, the requirement to enumer- 
ate the members of a group becomes problematic, particu- 
larly for groups with large numbers of individuals, or within 
organizations having large numbers of users. For example, 
in a typical corporate enterprise, new employees are fre- 
quently hired, and current employees may leave the enter- 
prise or change job descriptions with relative frequency. 
Moreover, employees may participate in a large number of 
different groups that span different aspects of an employee's 
standing within an enterprise. For example, groups may be 
defined based upon projects, management positions, human 
resources, facilities, accounting, geography, interests, skills, 
etc. 

Given that conventional groups require enumeration of 

45 members, whenever a new employee is hired, or an existing 
employee leaves or changes status, any groups that the 
employee is involved with (or will be involved with) typi- 
cally must be updated. As a result, and particularly if 
employees are members of large numbers of groups, or if 

50 groups have relatively large numbers of employees that are 
constantly changing, it can be extremely difficult to keep all 
of an enterprise's groups current, llie burden on adminis- 
trators just in keeping groups current can be significant, and 
can result in substantial expenditures of time and resources 

55 within an organization, if not be entirely prohibitive for 
some organizations. 

Moreover, given typical inefiGciencies within any 
organization, delays in manually incorporating changes into 
a computer environment after an employment status change 

60 are often inevitable. Particularly where individuals are 
granted authorities on a computer network based upon their 
employee status, or where groups are used for issuing 
critical communications to employees, delays in updating 
groups to reflect changes in employment status can limit 

65 employee productivity and otherwise hamper employees' 
abilities to perform their jobs. As an example, if a new 
employee has to use a particular software application to 
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perform his or her job, and access to that software applica- 
tion is reliant upon membership in a particular group, any 
delays in adding that employee to the group effectively 
hamper the employee's ability to do the job. 

In other environments, enumerated groups present addi- 5 
tional concerns. For example, substantial resources are often 
devoted to mailing lists and other direct marketing databases 
to create groups of individuals that share common interests 
and might be receptive to particular marketing promotions. 
Creation of such lists is often labor intensive, and in some lO 
instances requires the manual addition of members to a 
group used for the mailing list. Automated tools have been 
developed to assist in "crawling" the Internet for potential 
group members; however, any members found by a crawler 
are often required to be individually added to the group. 15 
Given that mailing lists may have tens or hundreds of 
thousands of individual members, the use of enumerated 
groups in such instances can be unwieldy and complex. 

Yet another limitation of conventional groups is that often 
the data structures representing such groups are required to 
be centralized within a single location, and often in an 
internal database having restricted access outside of a par- 
ticular enterprise computer network. In many instances, 
however, it may be desirable to define groups that span 
different "domains" (i.e., computer environments such as 
enterprise networks or subnetworks), and/or different enter- 
prises. Moreover, when different domains utilize different 
underlying database technologies to implement their user 
and group information, distributing a logical group across 
these various domains and enterprises is difficult. 

Therefore, a significant need exists in the art for a manner 
of organizing and managing groups to provide greater 
flexibility, adaptivity and extensibility, particularly for 
groups comprising large numbers of individuals and/or 
spanning multiple domains and/or enterprises. 

SUMMARY OF THE INVENTION 

The invention addresses these and other problems asso- 
ciated with the prior art by providing an apparatus, program 40 
product, and method that utilize "dynamic" groups to rep- 
resent collections of individuals in a computer environment. 
With a dynamic group consistent with the invention, a group 
membership criterion and a set of member identifiers are 
associated with one another within a dynamic group data 45 
structure, such that the set of member identifiers identifies 
those users from a plurality of users that meet the group 
membership criterion for the dynamic group. Moreover, 
through dynamic updates that may occur periodically and/or 
in response to predetermined events, the set of member 50 
identifiers for a dynamic group may be updated to reflect 
modifications to the plurality of users so as to maintain the 
identification of members in the dynamic group current, 
often with little or no manual intervention by an adminis- 
trator or other computer user. Consequently, in the case of 55 
large groups and/or groups utilized in connection with user 
pools that frequently change, the use of dynamic groups as 
described herein greatly facilitates maintaining current 
group memberships. 

Moreover, in some embodiments dynamic group data 60 
structures may be utilized in connection with multiple 
networked target computer environments having users that 
span multiple computer domains and/or enterprises. The 
target computer environments are networked with a hub 
computer upon which is resident a database that maintains a 65 
dynamic group data structure as described above, which 
may include users from multiple target computer environ- 
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ments. Within at least a portion of such target computer 
environments, mirrored group data structures may be dis- 
tributed and maintained, with each including at least a subset 
of member identifiers from the set of member identifiers 
associated with the dynamic group data structure. 
Furthermore, the target computer environments in some 
instances may be implemented using different underlying 
platforms, and/or may be under the control of different 
enterprises. Through automated synchronization between 
the hub computer and the target computer environments, 
however, changes made to the dynamic group data structure 
and/or a mirrored group data structure may be propagated 
throughout the networked system as necessary to maintain 
synchronization between all relevant group data structures in 
the networked system. 

These and other advantages and features, which charac- 
terize the invention, are set forth in the claims annexed 
hereto and forming a further part hereof. However, for a 
better understanding of the invention, and of the advantages 
and objectives attained through its use, reference should be 
made to the Drawings, and to the accompanying descriptive 
matter, in which there is described exemplary embodiments 
of the invention. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a bkx;k diagram of a multi -platform, cress- 
enterprise networked computer system incorporating a 
dynamic group management system consistent with the 
invention. 

FIG. 2 is a block diagram of the hub computer from the 
networked computer system of FIG. 1. 

FIG. 3 is a block diagram illustrating a user record utilized 
in the dynamic group management system of FIG. 1. 

FIG. 4 is a flowchart that illustrates the program flow of 
an establish group hub routine executed by the hub group 
manager in the dynamic group management system of FIG. 
1. 

FIG, 5 is a flowchart that illustrates the program flow of 
an establish group spoke routine executed by the hub group 
manager in the dynamic group management system of FIG. 
1. 

FIG. 6 is a flowchart that illustrates the program flow of 
a create group routine executed by the hub group manager 
in the dynamic group management system of FIG. 1. 

FIG. 7 is an object diagram illustrating an exemplary 
database schema utilized in connection with managing 
dynamic groups in an exemplary security management 
application of the dynamic group management system of 
FIG. 1. 

FIG. 8 is a block diagram of the utilization of the 
exemplary security management application having the 
database schema of FIG. 7. 

FIG. 9 is a block diagram of an exemplary content 
management application of the dynamic group management 
system of FIG. 1. 

FIG, 10 is a block diagram of an exemplary electronic 
messaging application of the dynamic group management 
system of FIG. 1. 

FIG. 11 is a block diagram of an exemplary software 
distribution application of the dynamic group management 
system of FIG. 1. 

DETAILED DESCRIPTION 

The embodiments described herein utilize dynamic 
groups to maintain group information for collections of 



04/06/2004, EAST Version: 1.4.1 



us 6,671,695 B2 

5 6 

individuals in connection with computer tasks are per- local-area, wide-area, public and/or private networks, and 
formed. As will become more apparent below, individuals using any number and combination of known topologies and 
are typically computer users, with a "user space" represent- protocols. For example, network interconnects 18 are illus- 
ing the set of users in a computer environment that are tratcd as coupling different spoke computers 16 to hub 
capable of being incorporated into groups. Moreover, in the 5 computer 14, whether be it through private means (e.g., 
context of a group, a user is considered to be a "member'' of jial-up connections) or through public means (e.g., via the 
that group if that user is to be mteracted with, or is to have Internet, represented at 20). 
a task performed on behalf of it, whenever a computer l^jj.-i . 
operation is to be performed on the group as a whole (e.g., , Moreover, any number of additional computers and other 
when the operation identifies or operates on the group devices may be networked into networked computer system 
explicitly, rather than specific individuals). ^° ^^^"^ ^"^^n 1° example, as wiU become 
Hie members of a dynamic group are defined based upon ^PP^^"^ ^'^^^Y; administration of dynamic group 
a group membership criterion, which may be based upon management system 12 may be performed via one or more 
practically any set of characteristics, attributes, or the like g^^^P admmistration workstations 22 coupled to a hub or 
that are capable of distinguishing a set of users from among ^poke computer 14, 16. Furthermore, individuals that par- 
a user space that meet the group membership criterion. As ^^^^P^^^ ^ members of a dynamic group may be accessible 
will become more apparent below, practically any type of client computers distributed across one or more enter- 
rule, test, or logic may be utilized to represent a group P"^^« ^'^'^^ ^"t^"^*^^ (""^ ^^own in FIG. 1). 
membership criterion consistent with the invention. For I" the illustrated implementation, dynamic group man- 
example, in the illustrated implementations below, a group agement system 12 incorporates a hub group manager 
membership criterion may comprise one or more selected program 30 that accesses a user database 32 and a group 
values of one or more "attributes" that identify various users database 34 resident on hub computer 14. Hub group man- 
within a user space. As such, when used in connection with ag^r program 30 manages the creation, modification, dele- 
a user record, an attribute typically is represented as a field lion and access to dynamic groups in a manner that will 
in a user record, with the value stored in that field rcprc- become more apparent below. 

scnting the value of the attribute. User database 32 includes a plurality of user records 36 
A group membership criterion may include Boolean logic that maintain information on individuals suitable for being 
operations such as AND, OR, NOT, etc, Acriterion may also incorporated into dynamic groups. User records 36 may also 
be used in a negative fashion, e.g., to exclude certain users be iised for other applications as is well known in the art. 
based upon certain characteristics of those users. Any number of database environments and/or directory 
Tlie set of member identifiers associated with a dynamic environments may be used to implement user database 32, 
group may be represented by any number of data structures, ^ g** ^tus Notes, Microsoft Exchange, Windows NT, an 
including linked lists, tables, and the like. Moreover, various ^DAP Directory, Novell NDS, other directory and/or 
mechanisms for identifying users may be used as member address book databases, proprietary databases, etc. 
identifiers, including, for example, user record ID*s, email 35 Group database 34 includes a plurality of master group 
addresses, names, and other distinguishing user character- records 38 that maintain information about the various 
istics. Moreover, pointers to user records may also be used dynamic groups managed by dynamic group management 
in some implementations. system 12. Any of the aforementioned database environ- 
Other modifications will be apparent to one of ordinary mcaXs suitable for use with user database 32 may be used for 
skill in the art having the benefit of the instant disclosure. 40 groi^P database 34. Moreover, in some implementations 
llierefore, the invention is not limited to the particular ma.ster group records 38 and user records 36 may be 
implementations discussed herein. managed in the same database. 

Turning now to the Drawings, wherein like numbers I" the implementation discussed hereinafter, for example, 
denote like parts throughout the several views, FIG. 1 ^s^r and group records are maintained in a hub computer 
illustrates a networked computer system 10 incorporating a 45 within a combined database that supports the Lightweight 
dynamic group management system 12 consistent with the Directory Access Protocol (LDAP) directory protocol, e.g., 
invention. Computer system 10 is illustrated as multi- Il^S (formerly GDS) available from Critical Path, 
platform, cross-enterprise computer system including one or Each spoke computer typically includes a spoke group 
more hub computers 14 coupled to one or more spoke manager 40 that is interfaced with a local user database 42 
computers 16 distributed among several enterprises (e.g., 50 and group database 44, within which is respectively main- 
enterprises A-D). Each enterprise may represent any num- tained user records 46 and group mirror records 48. While 
bcr of business organizations, whether non-profit or for- the principal dynamic group management components are 
profit, and may represent an individual or a non-business illustrated in only one of spoke computers 16 in FIG. 1, it 
organization as well. Each enterprise may represent a single will be appreciated that generally all such computers 16 
geographical location or multiple geographical locations. 55 incorporate the same or similar components. Of course, in 
Moreover, in some embodiments, dynamic group manage- some implementations, the various spoke computers distrib- 
ment may be limited to a single enterprise, whether in a uted within a system need not be identical in software or 
single location or in multiple locations. Moreover, it should hardware design, 

be appreciated that despite the fact that a dynamic group With respect to databases 42, 44, some or all of the user 
management system may be implemented within one or 60 records 46 may be duplicates or mirrors of user records 36 

more specific enterprises, the individuals represented within stored in the hub computer. In the alternative, the user 

a dynamic group need not be associated or affiliated with any records 46 may be completely different, and correspond, for 

particular enterprise (e.g., in the case of direct marketing example, to only those users that are managed by the 

groups, where individuals may be unrelated to the enterprise particular spoke computer or domain or enterprise within 
(s) seeking to market to them). 55 which such spoke computer resides. 

Hub and spoke computers 14, 16 may be interconnected llie group mirror records 48 in each spoke computer are 

via practically any known networking technology, including mirrored (i.e., at least partially replicated) copies of the 
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mastergroup records 38. In particular, the group-related data invention, a wide variety of application programs may 

in a master group record that is relevant to a particular access group manager programs 30, 40, e.g., electronic 

dynamic group is typically replicated to all group mirror messaging application programs, security management 

records. On the other hand, if the user records that match the application programs, software distribution application 
group membership criterion arc stored within the group 5 programs, content management application programs, etc. 

records, the group mirror records 48 may include only the Moreover, various operating system components may access 

identifications of the user rea)rds that are managed by that the aforementioned services consistent with the invention, 

spoke computer. In other embodiments however, the group ^ application program may access a dynamic group via a 

mirror records may store the identifications of all user ^ ^^-^^ ^^^^^^ ^„ the same or a different 

records that are members of a dynamic group, regardless of ^^^^ ^^^^ ^^-^^ appUcation program resides, 

domain or enterprise. Groups may be local, i.e., unique to a ^ V, ^ ... , . 

single platform and not referenceable within another group, ^IG. 2 illustrates in another way an exemplary hardware 

or they may be global, in which case they are universally and software environinent for an apparatus 60 consistent 

available in the group management complex supported, and ^^^^ ^^^^ invention, hor the purposes of the invention, 

may be included within other groups. apparatus 60 may represem practically any type ot 

A ^i-i. * u ^-^ I. r 1 J . I- computer, computer system or other programmable elec- 

As with hub databases 32, 34, each of spoke databases 42, , • ■. • • 1 j- i- . ft 

11 .J - 1 rj.t tronic device, including a chent or desktop computer, a 

44 may be implemented using any number or database 1 . *• . * li . 

TFAAn workstation, a server computer, a portable computer, a 

environments, e.g., LDAP-compatible directory environ- l ju u . i_ J . n . a 

... ^. t A£ AO handheld computer, an embedded controller, etc. Apparatus 

men is. Moreover, user and group muTor records 46, 48 may .„ , ■ r ' , u e j . « . 

. • , • I • u* iu t 4 u ' .-1 1 60 will hereinafter also be referred to as a "computer^ , 

be maintained within the same database in a particular spoke -,n u u u u ■ . ^ .1. . « » 
computer. Furthermore, as will become more apparent '° » though it should be appreciated the tenn apparatus may 

below, the native environment for each database 42, 44 can "'.^•"'^^ su"able programmable electron.c devices 

, , • u u J 1 » T-u c consistent with the invention, 
vary between any given hub and spoke computers. Thus, for 

example, even if the hub computer or one or more spoke Computer 60 typically includes at least one processor 61 

computers utilizes a Lotus Notes database, a spoke computer coupled to a memory 62. Processor 61 may represent one or 

in another domain in the same enterprise, or even within processors (e.g., microprocessors), and memory 62 

another enterprise, may utilize another database ^'^y represent the random access memory (RAM) devices 

environment, e.g., a Microsoft Windows NT LDAP Direc- comprising the main storage of computer 60, as well as any 

tory. As such, while dynamic group management system 12 supplemental levels of memory, e.g., cache memories, non- 
may be limited to use in a single computer, within a single 3^ volatile or backup memories (e.g., programmable or flash 

domain, utilizing a single database environment and con- memories), read-only memories, etc. In addition, memory 

trolled by a single enterprise, in other embodiments, such a ^^^y be considered to include memory storage physically 

system may be distributed among multiple hub and/or spoke located elsewhere in computer 60, e.g., any cache memory 

computers and/or may be multi-platform, multi-enterprise, a processor 61, as well as any storage capacity used as a 

and/or multi-domain in nature. ^i^^^al memory, e.g., as stored on a mass storage device 65 

To maintain synchronization between the various data- on another computer coupled to computer 60 via network 

bases within dynamic group management system 12, a interlace 66. 

synchronizer program (e.g., synchronizer programs 50, 52 Computer 60 also typically receives a number of inputs 
on hub and spoke computers 14, 16) is used. The synchro- and outputs for communicating information externally. For 
nizer program(s) perform a number of useful functions, 40 interface with a user or operator, computer 60 may include 
including maintaining synchronization between the respec- ""e or more user input/output devices 63 (e.g., a keyboard, 
tive user and group records on hub and spoke computers, as ^ mouse, a trackball, a joystick, a touchpad, a display device 
well as updating group memberships to reflect changes made such as a CRT monitor or LCD display panel, a speaker, etc. 
to the user records in the user databases. The synchronizer Otherwise, user input may be received via another computer 
program(s) may be configured to perform various tasks on a 45 interfaced with computer 60 through a workstation control- 
periodic basis, or may be configured to perform certain tasks ^cr 64, or over a network via network interface 66. 
in response to certain events. For example, an update to a For additional storage, computer 60 may also include one 
dynamic group may be triggered by an addition or deletion or more mass storage devices 65, e.g., a floppy or other 
of a user record in a user database. removable disk drive, a hard disk drive, a direct access 

A number of commercially available database synchroni- 50 storage device (DASD), an optical drive (e.g., a CD drive, 

zation tools may be used to implement the synchronizer a DVD drive, etc.), and/or a tape drive, among others. 

program(s) 50. For example, the InJoin Meta-Directory Furthermore, computer 60 may include an interface 66 with 

product from Critical Path of San Francisco, Calif, (among one or more networks (e.g., a LAN and/or WAN 74, and/or 

others) may be used to perform the necessary synchroniza- the Internet 20, among others) to permit the communication 
tion between the databases utilized by dynamic group man- 55 of information with other computers. It should be appreci- 

agement system 12. In the alternative, a proprietary solution ated that computer 60 typically includes suitable analog 

may be used. In either event, configuration of a synchronizer and/or digital interfaces between processor 61 and each of 

program to perform the necessary synchronization functions components 62, 63, 64, 65 and 66 as is well known in the art. 

described herein would be within the abilities of one of Computer 60 operates under the control of an operating 
ordinary skill in the art having the benefit of the instant 60 system 70, and executes or otherwise relies upon various 

disclosure. computer software applications, components, programs. 

Utilization of dynamic group management system 12 is objects, modules, data structures, etc. For example, FIG. 2 

typically via one or more application programs (e.g., appli- illustrates an application of computer 60 as a hub computer 

cation programs 54, 56 shown resident on hub and spoke as described above (similar components would be resident in 
computers 14, 16) having access to services provided by the 65 a spoke computer as described above in connection with 

group manager programs 30, 40. Given the wide variety of FIG. 1), including for example, hub group manager program 

end use applications of dynamic groups consistent with the 30, synchronizer program 50 and application program 54 
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resident in memory 61, and user and group databases 32, 34 selecting among users in a particular application, no exten- 

shown resident in mass storage 65 (and further shown sion of the LDAP InetOrgPerson class may be required, 

implemented within a combined LDAP-compatible database FIGS. 4-6 next illustrate a number of routines executed 

72). Moreover, various applications, components, programs, by a dynamic group management system to install dynamic 

objects, modules, etc. may also execute on one or more 5 group functionality in a distributed, multi-enterprise com- 

processors in another computer coupled to computer 60 via puter environment, which will also be referred to hereinafter 

a network, e.g., in a distributed or client-server computing as an Extended Enterprise Community (EEC). In this exem- 

environment, whereby the processing required to implement plary implementation, it is anticipated that an extended 

the functions of a computer program may be allocated to community of users spanning multiple enterprises are 

multiple computers over a network. capable of being linked together into groups that span the 

In general, the routines executed to implement the digital boundaries of different domains and enterprises, 

cmbodimentsof the invention, whether implemented as part To implement dynamic groups within such an 

of an operating system or a specific application, component, environment, it is desirable to first establish a group hub, 

program, object, module or sequence of instructions will be representing the master site from which groups are defined, 

referred to herein as "computer programs", or simply "pro- ^5 FIG. 4, for example, illustrates an establish group hub 

grams". The computer programs typically comprise one or routine 140 which is executed to initialize dynamic groups 

more instructions that are resident at various times in various °° ^ computer. 

memory and storage devices in a computer, and that, when Routine 140 begins in block 142 by installing a hub group 

read and executed by one or more processors in a computer, manager application on the hub computer. Next, block 144 

cause that computer to perform the steps necessary to ^^t^ro^ines whether an LDAP durectory is instaUed. If not, 

execute steps or elements embodying the various a.specLs of ^"^^^^^ P^^ses to block 146 to install the LDAP directory, 

the invention. Moreover, while the invention has and here- Control then passes to block 148 to add the aforementioned 

inafter will be described in the context of fully functioning extension fields to the LDAP schema. Alternatively, if block 

computers and computer systems, those skilled in the art will 1^4 determines that the LDAP directory is already installed, 

appreciate that the various embodiments of the invention arc 25 ^^^^^ ^ bypassed, and control passes directly to block 
capable of being distributed as a program product in a 

variety of fonns, and that the invention applies equally Next, block 150 creates a group in the Group of Names 
regardless of the particular type of signal bearing media used object class defined by the LDAP standard to hold the name 
to actually carry out the distribution. Examples of signal of hub administrators of the application at the hub computer, 
bearing media include but are not limited to recordable type 3^ Next, block 152 creates a spoke administrator group to be 
media such as volatile and non-volatile memory devices, used to hold the names of the spoke administrators for the 
floppy and other removable disks, hard disk drives, magnetic system. The hub and spoke administrator groups may be 
tape, optical disks (e.g., CD-ROM*s, DVD's, etc.), among enumerated groups under the LDAP standard, 
others, and transmission type media such as digital and Next, block 154 adds one or more administrators to the 
analog communication links. hub administrator group, with such administrators granted 
In addition, various programs described hereinafter may authority to create groups, add other group administra- 
be identified based upon the application for which they are tors and add spokes and spoke administrators. The admin- 
implemented in a specific embodiment of the invention. istrators defined in block 154 are referred to as group hub 
However, it should be appreciated that any particular pro- administrators. Upon completion of block 154 routine 140 is 
gram nomenclature that follows is used merely for 40 complete. 

convenience, and thus the invention should not be limited to FIG. 5 next illustrates the process for establishing a group 

use solely in any specific application identified and/or spoke in another computer domain or enterprise. In 

implied by such nomenclature. particular, FIG. 5 illustrates an establish group spoke routine 

Those skilled in the art will recognize that the exemplary 160 that begins in block 162 by installing a spoke group 

environments illustrated in FIGS. 1 and 2 are not intended 45 manager application on a spoke computer within the target 

to limit the present invention. Indeed, tho.se skilled in the art computer environment within which a group spoke is 

will rec-ognize that other alternative hardware and/or soft- desired. Next, block 164 determines whether an LDAP 

ware environments may be used without departing from the directory is currently iastalled on the spoke. If not, control 

scope of the invention. passes to block 166 to install the LDAP directory. 

Now turning to FIG. 3, an exemplary user record 36 is 50 Otherwise, if the LDAP directory is already installed on the 

illustrated in greater detail. User record 36 may be ^P^^e, block 166 is bypassed. 

implemented, for example, using an extended LDAP record Next, block 168 grants authority to the group hub admin- 
object such as an extended object based upon the LDAP is tralor for inter acting with the group spoke infrastructure. In 
InetOrgPenson object class, which is well known in the art. particular, the group administrator is granted read authority 
The extended record object 36 therefore includes a plurality 55 on the InetOrgPerson object class, and granted create/read/ 
of LDAP-defined attributes 80, with the addition of one or update/delete authority on the Group of Names object class, 
more extension attributes 82 representing additional Next, in block 170, the aforementioned extension fields 
attributes suitable for use in networked computer system 10, are added to the LDAP schema on the group spoke. Next, in 
in particular to support dynamic groups consistent with the block 172, the newly-created group spoke is added to the 
invention. To support dynamic groups, a conventional 60 group spoke table in the group or application. In this context, 
LDAP InetOrgPerson object may be extended with one or the group spokes may be considered to be domains that hold 
more attributes for which it is desirable to distinguish users users and attributes about the users, and that are the basis for 
and thus permit the selection of members from the user providing user data that may be used in group inclusion 
space. Typically, it is also desirable to include an additional rules. Additionally, as described above, each group spoke 
field that identifies what groups a particular user is a member 65 may have groups "pushed" to it by the group hub. 
of, particularly for performance reasons. Otherwise, if the Next, in block 174, one or more administrators are added 
attributes defined by the LDAP protocol are sufficient for to the spoke administration group. In the illustrated 
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implementation, all group spoke administrators have full 
group management privileges for all group spoke computers 
registered to them. 

Next, in block 176, a prefix for each spoke computer is 
created and added to a master prefix table. It is intended that 
all groups created by the spoke administrator will have this 
prefix as a standard part of its group name. 

Next, in block 178, the spoke administrator is permitted to 
create one or more delegates for performing spoke admin- 
istration. Routine 160 is then complete, resulting in the 
establishment of a group spoke on one of the spoke com- 
puters in the networked computer system. It will be appre- 
ciated that routine 160 may be executed for each domain or 
enterprise for which it is desired to add a group spoke. 

FIG. 6 next illustrates a create group routine 180 initiated 
by any user with group administrator privileges, whether a 
hub group administrator or a spoke group administrator. 
Typically, routine 180 is initiated through interaction by 
such authorized user with the appropriate hub or spoke 
group manager application running on the computer through 
which the user is interacting with the dynamic group man- 
agement system. 

Routine 180 begins in block 182 by authorizing the u.ser 
as a hub or spoke group administrator. It will be appreciated 
that if the user initiating routine 180 does not have sufiScient 
authorization, routine 180 may be terminated prematurely. It 
should also be appreciated that block 182 may incorporate 
additional security features such as requiring the input of a 
password by the user to verify his or her administrator status. 

Next, in block 184, the administrator specifies the group 
membership rules for a new group. In the illustrated 
implementation, this may be performed in attribute -type/ 
attribute-value pairs, e.g., through the selection of appropri- 
ate values from among a fixed set of available values for 
each attribute. As such the establishment of rules may be 
made through a graphical user interface incorporating con- 
trols such as radio buttons, list boxes, check boxes and the 
like. 

Among the membership rules defined in block 184 arc a 
membership domain list and a membership criterion. The 
membership domain list includes the domains from which 
users can be selected. Typically, if no domain is specified, all 
users in the extended enterprise community will be available 
for inclusion, with the specified membership criterion 
applied to all domains. 

The membership criterion reflects the attribute types and 
values that arc the basis for group inclusion by users. Any of 
the attributes, or a combination thereof, may be utihzed in a 
group membership criterion consistent with the invention. 
Moreover, at this time logic rules, e.g.. Boolean connectors, 
may be specified. 

Next, block 186 defines the group distribution rules, 
which specifies where the group is to be distributed. The 
options may include leaving the group exclusively in the 
hub. It should be appreciated, that even with the group 
maintained within the hub, spoke computers, as well as other 
user computers distributed throughout a networked com- 
puter system, may still access the hub computer to utilize the 
created group. 

In the altemative, an administrator may specify that a 
group is distributed to all spokes in the EEC. Moreover, in 
some embodiments it may be desirable to permit an admin- 
istrator to select to which specific spokes the group should 
be distributed. 

Next, block 188 defines group synchronization rules, 
which specifies when a group is to be distributed and 
updated. In the illustrated implementation, both periodic and 
event-based synchronization may be supported. Thus, for 
example, an event -based synchronization may be selected to 
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permit near real-time synchronization of hub and spoke 
group records in response to changes made throughout the 
system. For example, synchronization may be triggered 
upon modifications to one or more user records in a hub 

^ and/or spoke user database. Synchronization may also be 
triggered based upon changes to a group data structure in 
either or both of a hub or spoke group record (e.g., changing 
the domain list, the synchronization and/or distribution 
rules, and/or the membership criterion). Other events, for 
example a predetermined synchronization schedule, or real- 
time "synch now'* command, may be used to trigger syn- 
chronization and dynamic update of a dynamic group con- 
sistent with the invention. 

Another altemative for group distribution is that of peri- 
odic distribution, whereby group records present on the hub 

35 and spoke computers are synchronized at predetermined 
intervals. Moreover, it should be appreciated that different 
periodic intervals may be specified for dynamically updating 
group membership and synchronizing hub and spoke group 
records. 

20 Another option for distributing groups is a one-time 
distribution, whereby spoke computers are initially pushed 
the initial group record for a dynamic group, with no further 
synchronization performed until manually specified by an 
administrator. Such a configuration may be desirable when 

25 dynamic group functionality is used solely to facilitate the 
initial creation of a large group. 

Once the group synchronization rules are defined in block 
188, block 190 filters the LDAP directories in each of the 
group domains (hubs and spokes) using the membership 
criterion defined for the group, e.g., using a known filtering 
process to return identifiers or keys to the matching directory 
entries. As such, the person objects in the hub and selected 
spokes are scanned and filtered based upon the membership 
criterion. 

Next, block 192 instantiates the group object in the hub, 
•'^ and populates the hub with the membership domain list, the 
membership criterion, the group distribution rules, the group 
synchronization rules, and a list of identifiers for the users 
that initially satisfy the membership criterion within the 
specified membership domains. 

Next, block 194 replicates the group record to the desig- 
nated spoke environments based upon the distribution and 
synchronization criteria. Once the group has been replicated, 
block 196 then creates any delegates for group administra- 
tion as specified by the administrator that has created the 
45 group, and routine 180 is then complete. It should be 
appreciated that the designation of clelegates for either 
group, hub or spoke administration may be optional in some 
environments. 

In some implementations, it may be desirable to add 
50 exceptions to groups, such that not all members are com- 
pletely consistent with the group membership criterion. In 
such instances, it may be desirable to create an exception 
group that is hand-populated through enumeration, and used 
to add or remove selected members to and from the 
dynamically-generated list of members for the group. In 
other environments, however, such functionality may be 
omitted. 

Once a group is created, synchronization is performed at 
the intervals described above. Such synchronization may be 
performed via proprietary routines. In the alternative, the 
aforementioned synchronizer application may be utilized to 
perform such synchronization. As a component of 
synchronization, dynamic updates of the group and/or spoke 
group memberships may be performed simply by perform- 
ing the aforementioned LDAP filtering and selection opera - 
65 tion based upon the current settings for a particular group 
(e.g., as described above in connection with block 190 of 
FIG. 6). 
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Furthermore, it will be appreciated that the creation of 
group spokes in various domains may rely on differing 
underlying platforms. However, given the support of the 
LDAP directory standard across all platforms, any differ- 
ences in the underlying platforms may be minimized from 5 
the standpoint of the dynamic group management system. In 
some applications, however, additional customization may 
be required to suitably implement the dynamic group man- 
agement system within various types of platforms. 

Once groups are established, utilization of the groups 
typically comprises the access of such groups via one or 
more applications executing in a hub computer and/or with 
a target computer environment (e.g., one of applications 54, 
56 shown in FIG. 1). As is well known in the art, each group 
manager (e.g., group managers 34, 40 of FIG. 1), may 
expose one or more services, e.g., via API routines, remote 
procedure calls, remote object invocations, dynamic link 
libraries, XML services via HTTP, etc. through which a user 
interacting with a dynamic group management system via 
any of hub and spoke computers may interact with the 
group. In fact, from the standpoint of a user or end-use 20 
application, services that are similar or identical to those 
provided by enumerated groups may be provided by a 
dynamic group management system such that the dynamic 
functionality implemented within the herein-described 
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dynamic groups is effectively hidden from end users. Put 
another way, the dynamic groups may be used and interacted 
with in the same manner as enumerated groups. As such, 
retrieval of group members, and other group-related func- 
tions known in the art may be performed by a user inter- 
acting with a dynamic group consistent with the invention. 

While the dynamic groups described herein have a wide 
variety of applications, a number of specific exemplary 
applications are described hereinafter, starting with a secu- 
rity management application in which authorization to com- 
puter resources is controlled based upon a user's member- 
ship in a dynamic group. Other applications, including 
software distribution, content management, and electronic 
messaging, are also described hereinafter. 

Security Management Application Implementation 

FIGS. 7-8 illustrate one exemplary application of 
dynamic groups in implementing security management 
functionality throughout a multi-enterprise/multi-domain 
computer environment. In this exemplary implementation, 
the LDAP InelOrgPerson object class is extended to incor- 
porate the attributes listed below in Table I. The extended 
attributes are distinguished from conventional LDAP 
attributes by virtue of an **Ext" prefix on the attribute 
identifier. 



TABLE I 



EXPENDED IDAP OBJECi^ AITRlBLTt'ES 



LDAP AITRIULrrE 



DEFINITION OFATTRIBLriE 



commonName or cn 
ExtPrefix 
givenName 
initials 

ExtMiddlcName 
Extlnitials 
surName or sn 
uid 

EmployeeTypc 

ExtStatus 

ExtCompany 

ExtHireDate 

ExlNotcsMail 

mail 

telephone Number 
ExtExtension 
ExtAltPhone 
ExtStarnet 

fascimileXelephoncNumber 

ExtFaxScrvcr 

ExtStarnctFax 

ExtTclcphony 

mobile 

pager 

sccretar>' 

sceAlso 

manager 

ExlPhotoURL 

ExlOrgType 

ExtOrgName 

departmentNumber 

ExtDepartmenlName 

businessCategory 

ExiSubCategory 

ExtSegmcnt 

ExtCostCodc 

Ext Function 

title 

ExtRoie 

ExtRegion 

ExtCountry 

St 

ExtCity 



User/employee full name 

User/employee naming prefix (Mrs, Ms, Mr, Dr etc.) 

User/employee first name 

User/employee initials 

Uscr/employcc middle name 

Extended initials (if duplicated initials exist) 

Uscr/cmployec last name 

Unique ID 

Description of uscr/cmployec's status 
Extension to status (0 » Active, 2 « Inactive) 
Company name of contractors 

Date user/employee most recently began work @ company 
Internal email address used by user/employee to send internal 
messages 

Internet-standard format email address used by user/employee. 

User/employee telephone number 

Extension of User/employee woit phone number 

Alternate phone number 

Internal company phone number 

Fax number 

Fax server 

Internal company fax number 
Telephony Information 
Mobile phone number 
Pager phone number 

Name of the user/employee's administrative assistant 

Name of the user/employee's alternate or backup 

Name of the user/employee's manager 

A ".gif ' or ".jpeg" file containing user/employee's picture 

User/employee's business unit type 

User/employee's business unit name 

User/employee department number 

User/employee department name 

Grouping of products with related uses 

Product family 

Grouping of products with single intended use by consumer 

User/employee cost center code 

User/employee company division 

Description of the user/employee's job 

User/employee "role" in business unit 

Location of user/employee, based on a Global standard 

Location of user/employee, based on country 

Location of user/employee, based on divisions within country 

Location of user/employee based on divisions within state 
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1/\J3L(C i-cuniinucu 




EXTENDED LDAP OBJECT AlTRIBLritiS 


LUAr Al 1 KIBUi b 


DErlNIIlON Or Al IKLbLTlb 


PostalCode 


Postdl code of 3rc3 in whicli uscr/cmploycc works 




ExL&nml n^fliling Bcldrcss 


Exl Building 


Company-owned builduig in which user/employee works 


ExtSttc 


Compsny site 


Ext Floor 


nvjui uii wiiiwi vLaci/diLLJiij y wviivo 


TOO m Wumbs r 


User/employee room number 


Extin tMailBox 




pos tulAddrcss 


Full posUil nddress used to route m&ii extcrnnlly to user/employee 


Ext Project 


Description of user/employee's p&st/p resent project Qssignments 


Ext Expe rt LS 6 


Description of business~relnted skills or Eircfis of expertise 


Ext 1^ n ^^&gc 


1>dn^^A^cs spoken by uscr/cmploycc 


Extlntcrcst 


Description of businesS'^rcldtcd skills or drcES of interest 


ExtTcam 


P&st flnd present tcfiiris thBt user/employee hds been b member 


Ext Initiative 


P^st Qnd present rnitiBtivcs thst user/employee h3s been d member 


Ext Ho in cTo wn 


User/employee home to'wn 


Ext Sec 0 ndn r y 






User/employee secondary school^ snd degree e3rned 


Ext Degree 




iL Al o 1 gn w in CI 


Wtime of spouse/signinc^nt olher 






Ext Hobby 


Activities or sports 


ExtAffliation 


Org3niz£itions user/cmptoyee is involved with outside company 




A 11 tomtit If* rtT 1T19 nil!) 1 iirtHat^ f1 fi ft 


CiAl u puaic 1 inic 


Time in which entry was updated 


Ext Sou rce 


Source for entry 


Ext Platform 


Platform/System identifiers 


ExtShortNamc 




ExtGloPN 


Olobal Personnel Number 


cmployccNumbcr 


l^cat employee ID 


Fvf Aitin 


Alternate computing ID s 


Ext Handle 




Ext Nla L 1 Sc rv'c r 


Email sci\^er name 


ExtNlailDomain 


Email Domain 


Ext P re ngua gc 


Preferred Language 


ExtRe qP la tfo rm 


Recjucsted platforms 


ExtApprovc r f or 


Platform A^pproval 


ExtNtDomain 


NT Domain 


ExtMailFile 




Ext App 1 Lca t lo n 


Application object class for non'^people account information! 


Fvt.Q**ccinTi 
l^AlOCooiUll 


Object class to hold login session information. 


Fvt Qpr*tiri tv^^Kipr*!" 
CfAioc^ui iiy v/ujcui 


Object class to hold password security information. 


Fvt nicnM^/) 








ExtMaxDays 


Length of time in days that passwords arc valid 


iwAiF wui^ Alalia ngc Ua 




ExtPwdHxpirationOatc 


Date password expires 


Li^Ll liUir WUl 


'1 ct nr^vi/^iic r^ft c ctx*/^ rH 
J. At prc> iuua pa3S>wuru 






ExtFrioiPwd3 


3rd previous password 


ExtPriofPwd4 


4th previous password 


ExtPriorPwdS 


5th previous password 


ExtChallengeQuestion 


Password question 


Ext Challenge Answer 


Password question answer 


Ext Challenge Pwd 


Challenge password 


extpwFailQjunt 


Number of failed login attempts since last successful login 


extpwFailTIme 


Tunestamp of last failed login attempt 


extLastLoginTime 


Timestamp of last successful login attempt 



Given the LDAP object class structure shown in Table I, 
any number and combination of the listed attributes may be 
utilized in defining the membership criterion for a dynamic 
group, including attributes in areas such as location, user 
employment status, user interests, user capabilities, user 
education, etc. Moreover, it will be appreciated that other 
combinations of attributes may be added to an LDAP object 
depending upon the desired application and bases for select- 
ing users into dynamic groups. It will also be appreciated 
that other, non-LDAP user records may be used in the 
alternative. Thus, the invention is not limited to the specific 
LDAP object implementation discussed herein. 

In the exemplary security management implementation 
discussed hereinafter, the user and group databases are 



55 integrated into a common LDAP-based directory database. 
To support dynamic groups consistent with the invention, a 
database schema should be designed to support the concepts 
of users and groups. One such suitable database schema 100, 
suitable for use in the security management application 
described hereinafter, is illustrated in FIG. 7, and includes a 
plurality of tables 102-134. Descriptions of the fields in each 
of tables 102-134 are presented below in Tables II-XVIII: 

65 

Table 102 stores user information, and is formatted as 
shown in Table II: 



55 



60 
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TABLE 11 



gds_t_User 



Column Name 



Description 



Uscr_Id 

Login_Naine 

Last_Name 

First_Name 

Initial 

Secu fit y__Admin 
Directory^Admin 
limploycc 
Status 

Transaction_Date 

Transaclio n_Owne r Id 

<additional fields> 



Internal field for Unking user to other database objects. 
Login Name of a user. 
User's last name. 
User's first name. 
User's middle initiaL 

Indicates whether user has Security Administrator's privileges. 

Indicates whether user has Directory Administrator's privileges. 

Whether user is an employee. 

Indicates whether user is active or deleted, 

Date when the last transaction was committed by a user. 

User_Id that committed the last transactioo. 

<additional fields as described above > 



Table 104 stores information about which users are in 
which security groups, and is formatted as shown in Table 
III: 



25 



Table 108 stores information about which users are del- 
egates of which security groups, and is formatted as shown 
in Table V: 



TABLE III 



gds_t_Group_Memberships 



Column Name Description 



30 



User_Id Internal field for associating user to a security group. 

Group_Id Internal field for associating user to a security group. 

Sub_Group The subgroup number of which the user is member of. 

Status Determines whether member needs to added to a group 

on the domains. 



35 



Column Name 



TABLE V 



;ds_t_Group_De legates 



Description 



Group_Id Group that the user is a delegate o£ 

Delegate Jd User that is delegate of the security group. 



40 Table 110 stores information about which global groups 

Table 106 stores information about security groups, and is are in which local groups, and is formatted as shown in Table 

formatted as shown in Table IV: VI: 

TABLE IV 



gds_t_Group 



Column Name 



Description 



Group Id 

Group__Name 
GrGup_Description 
Group_Owne r_Id 

Total_Sub Groups 

Membe rsh ip_Cl assificatio n 
Rule_Classification 
Membe rsh ip__Type 

Group_Type 
Group_Status 
Membe rship__Status 

Transaction Date 

'l'ransaction_Owner_Id 



Internal field for linking groups to other database objects. 
Name of the security group. 
Description of the security group. 
Security group owner. 

Total number of subgroups in which the security group is divided into. 

Flag for classifying who can view group memberships. 

Flag for classifying who can view group definition criteria. 

Flag to indicate whether group membership changes automatically based 

on auribute type, attribute value and user associated attribute changes. 

Type of the group (global/local). 

Used for batch processing of group and membership maintenance. 
Flag to indicate whether group membership needs to be adjusted. 
Date when the last transaction was committed by a iwcr. 
Uscr_Id that committed the last transaction. 
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TABLE VI 




TABLE Vl-continued 




gds_t_Group_Hierarchy 


^ Column Name 


fids. t Group. Hierarchy 
Description 


Column Name 


Description 


Transaction_Date 


Date when the last transaction was committed 
by a user. 

_Id User Id that committed the last transaction. 


Local_Group_Id 


Local group that contains the global group. 


Transaction_C)wner_ 


Global_Group_Id 


Global group that is in the local group. 


10 




HicraTchy_Status 


Used for batch processing of group 
maintenance. 


Tabic 112 stores information about domains, and is for- 



matted as shown in Table VH; 



TABLE VII 



Column Name 



ads_t__ Domain 



Description 



Domain_Id Internal field specifying a domain. 

Domain_Namc Domain name. 

Domain_Typc Domain type, e.g., NT or Notes. 

Master_Domain Indicates whether this is the master (hub) domain. 

Domain_Status Used for batch processing of group and membership maintenance. 

Transaction_Datc Date when the last transaction was committed by a user. 

Transaction_C)wncr_Id User_Id that committed the last transaction. 



Table 114 stores information about which security groups 
3Q exist on which domains, and is formatted as shown in Table 
VIII: 

TABLE VIII 

gds_t_G roup_Do mains 

35 

Column Name Description 

Group_Id Internal field for mapping security group to a 

domain. 

Domain_Id Internal field for mapping security group to a 

domain. 

GD__Status Used for batch processing of group 

maintenance. 

Transaction_Date Date when the last transaction was committed 

by a user. 

'^5 Tran5action_Owner_Id Uscr_Id that committed the last transaction. 



40 



Table 116 stores information about security group defi- 
nition criteria, and is formatted as shown in Table IX: 



TABLE IX 



gds t Group_Definition 



Column Name 



Description 



Group_Id Group to which the definition belongs to. 

Group_ConditLon_No Internal number as part of the primary key. 
Attribute_TVpe_[d Attribute type that is used in defining criterion. 
Attribute_Condition Comparison operator in group definition criteria. (IS/IS NOT) 
Attribute_VfeIue_Id Attril)ute value used in group definition criterion. 

Logic_operator Logical operator combining various attribute types to form a group definition 

criterion. (AND/OR) 

Sort_Order Order in which attribute type criteria will be displayed on security group 

definition screen. 

Transaction_Date Date when the last transaction was committed by a user. 

Transaction_Owner_Id User_Id that committed the last transaction. 



04/06/2004, EAST Version: 1.4.1 



us 6,671,695 B2 



21 



22 



Table 118 stores iDformation about attribute types, e.g., 
"Organization," and is formatted as shown in Table X: 

Table X 



Column Name 



Kds_t_Attribute_Tvpe 
Description 



Attribute_Typc_Id 

Attributc_Typc_Na mc 
Attributc_1Vp c_desc 
Attribute_Data_Type 
Data__Lcngth 
ContioI_iype 

DefauU_\^lue 
Attribute_Type_Owne r_Id 
Attribute_1Vp e_Status 
Transaction„Date 
Transaction_Owner„Id 



Interna I field for associating attribute type with users, security group 

definitions and other database objects. 

Name of attribute type, e.g., "Organization, Function, etc." 

Description of the attribute type. 

Data type of the attribute. 

Maximum permissible length of the attribute value. 

Type of control that needs to be used to display attribute value, e.g., 

'Text Box," "Check Box," etc. 

Default attribute value that will be displayed on control. 
Owner of the attribute type. 

Used for batch processing of group and membership maintenance. 
Date when the last transaction was committed by a user. 
User_Id that committed the last transaction. 



Table 120 stores information about which users can 
maintain attribute pick lists, and is formatted as shown in 
Table XI: 



TABLE XI 




cds t Attrribute De legates 


Column Name 


Description 


Attiibute_lYpe_ld 


Attribute type that can be maintained by a user. 


Delegate_ld 


User that can maintain the attribute type. 
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Table 122 stores information about which attribute values 
are associated with which user, and is formatted as shown in 
Table XII: 



35 



TABLE XII 



Column Name 



gds_t_User^Attributes 
Description 



User_Attribute_Id 
User_Id 

AUribute__Type_Id 
Attribute_Value_Id 

User Attribute Status 

Transactio n_Datc 
Transactio n_Own cr_I d 



Internal field to associate attribute value with user. 

Internal field to associate attribute value with user. 

Internal field to associate attribute value with user. 

Internal field to associate attribute value with user. 

Used for batch processing of group and membership maintenance. 

Date when the last transaction was committed by a user. 

Uscr_Id that committed the last transaction. 



Table 124 stores information about valid attribute values 
associated with attribute type, and is formatted as shown in 
Table XIII: 

TABLE XIII 

fids_t„Valid„Attr_\^lues 



Column Name 



Description 



Valid_Attribute_ld 
Attribute_'I\pe_Id 
Attr ibute_ Va lue_C har 
Attributc_ Va Iuc_Da te 
Attr ib ute_ Va fue_Nu mbc r 
Vaild^ttribute_Status 



Internal field to associate attribute value with attribute type. 
Internal field to associate attribute tjpe with attribute type. 
String value for the attribute. 
Date value for the attribute. 
Integer value for the attribute. 

Used for batch processing of group and membership maintenance. 
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TABLE Xlll-continued 

gds L Vatid . Attr Values 
Column Name DcsCTiption 

Transactioa_Date Date when the last transaction was committed by a user. 

Transaction_Owner_Id User_Id thai committed the last transaction. 



10 

Table 126 stores audit information about which users/ 
global group is added and deleted from which security 
group, and is formatted as shown in Table XIV: 



TABLE XIV 



fids t Group .Memberships Log 



Column Name 



Description 



Oroup_Id Internal field for associating user to a security group. 

Group_Namc Name of the group for which membership was changed. 

Member_Id User Id or Group Id for which membership was changed. 

Member_Name Name of the member. 

Member_Type Type of a member. 

Sub_Group The subgroup number of which the membership was altered. 

Domain_Id Domain id on which the membership was altered. 

Domflitt_Name Domain name on which the membership was altered. 

Transactioa_Status Membership added/deleted 
Transaclion_Date Date on which membership was changed. 

Transaction_Owncr_Id Id of the user that caused the membership changes. 
Trigger_Flag Process that triggered membership changes, e.g.:. 

0 - Member added because of new criterion added to a group definition. 

1 - Member added because of attribute association with user. 

2 - Member added because of global group added to a local group. 

3 - Member added because of existing group being associated with new 
domain in directory. 

4 - Member deleted because deleted group definition criterion. 

5 - Member deleted because of attribute dissociated from user. 

6 - Member deleted because the user was deleted from directory. 

7 - Member deleted because the global group was deleted from directory. 

8 - Member deleted because the attribute type was deleted from directory. 

9 - Member deleted because the attribute value is deleted from directory. 



40 

Table 128 stores auditing information about the creation 
and deletion of security groups on different domains, and is 
formatted as shown in Table XV: 



TABLE XV 



fids_t_Group„IjOfi 



Column Name 



Description 



Group_Id 

Group_Name 

Domain_Id 

I>omain_Name 

Domain_Type 

Mastcr_Domain 

Group_Description 

Group_Owner_Id 

GT0up_Owner_Name 

Mcmbership_Classification 

Rule_Classification 

Membership_Type 

Group_Type 

Group_Status 

Transaction_Date 

Transaction_Owner Id 

Success_Flag 



Internal field for linking groups to other database objects. 
Name of the security group 

Domain Id on which the group was created or deleted from. 

Name of the domain on which the group was created or deleted from. 

Domain type, e.g., NT or Notes. 

Indicates whether this is the master (hub) domain. 

Description of the security group. 

Security group owner 

Owner name for the group. 

Flag for classifying who can view group memberships. 

Flag for classifying who can view group definition criteria. 

Flag to indicate whether group membership changes automatically based 

on attribute type, attribute value and user associated attribute changes. 

Type of the group. 

Used for batch processing of group and membership maintenance. 
Date when the last transaction was committed by a user. 
User_Id that committed the last transaction. 

Flag to identify whether the transaction was partial or con^lete success. 
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TABLE XV-continued 

fids t . Group Log 

Column Name Description 

Triggcr^Rag Process that triggered the batch process for maintenance of the groups 

on domains, e..g: 

0 - Group Added to domain because a new group was created in 
directory. 

1 - Group Added to domain because an existing group in director^' was 
associated with a domain. 

2 - Group deleted from domain because a group was deleted &om 
directory. 

3 - Group deleted from domain because a group was removed from a 
domain in directory. 

4 - Group was deleted from domain because the domain wa.s deleted 
from directory. 



Table 130 stores information about error messages thai 
need to be displayed by the application for different errors, 
and is formatted as shown in Table XVI: 



TABLE XVI 




fids t Error Code 


Column Name 


Description 


Error_Codc 


Error Code. 


Error Message 


Error Message that needs to be displayed. 



Table 132 stores system parameters that are used by the 
application, and is formatted as shown in Table XVII: 



TABLE XVII 





t Configuration 


Column Name 


Description 


Param_Key 


Key for the parameter. 


Pa ram_ Value 


V^lue of the system parameter 



Table 134 stores information on reports and reporting 
access, and is formatted as shown in Table XVIII: 



TABLE XVIII 





gds_t_RcnorL<i 


Column Name 


Description 


Report„Id 


Internal field specifying a report. 


Description 


Report Description. 



It will be appreciated that the definition of a suitable 
database schema for any specific application will be highly 
application dependent. Therefore, the invention is not lim- 
ited to the particular schema disclosed herein. 

Utilization of the aforementioned dynamic group man- 
agement system in a security management apphcation 200 is 
illustrated in greater detail in FIG. 8, As shown in the figure, 
an LDAP hub directory 202, organized as discussed above 
in connection with FIG. 7, is populated with one or more 
group policies 204, representing the group a)n figuration 
information described above, e.g., group membership 
criterion, domain selection criterion, distribution and syn- 
chronization rules, group ID, etc. Each group policy also 
includes security authorization information representative of 
the permitted and/or prohibited activities to be associated 
with the members of each group. 



In addition, user data 206 corresponding to one or more 
20 users is entered into the LDAP directory to create one or 
more user records representative of users capable of being 
authorized via security management. As shown in block 208, 
one or more groups are created based upon desired group 
policies, and selected users are dynamically added to the 
new groups based upon the membership criteria associated 
with the various new groups (as described above in connec- 
tion with FIG. 6). The result of block 208 is the addition of 
new groups to the LDAP directory, now represented at 210. 

Next, as shown at block 212, the dynamic groups main- 
tained in directory 210 may be pushed to one or more 
application-specific directories, and/or to one or more spoke 
directories. In the alternative, direct lookups to the hub 
directory 210 may simply be supported, e.g., via remote 
procedure calls or remote object invocations. 

Also provided to the end-use directory 212 (i.e., the hub 
35 directory, a spoke directory or an application-specific 
directory) is a security management process 214, repre- 
sented by one or more Access Control Lists (ACL's). Each 
ACL typically includes a resource identifier, representing 
the resource(s) begin protected; a privilege identifier, rep- 
40 resenting what actions are permitted on the specified 
resource(s); and a list of authorized entities capable of 
accessing the specified resource(s) with the specified per- 
mitted actions. In the case of dynamic groups, the list 
includes a group ID for the dynamic group(s) to be associ- 
ated with the ACL. Other entities, such as individuals and 
enumerated groups, may also be associated with an ACL as 
weU. 

As shown in block 216, whenever an application needs to 
make a security check before performing a particular action, 
the application accesses the security management system to 
retrieve the ACL associated with that action. As is well 
known in the art of security management, the requested 
action will be permitted if the user is authenticated as having 
the appropriate rights based upon the appropriate ACL. In 
the case of a user that is a member of a dynamic group, 

55 therefore, the rights will be based upon a determination that 
the user is a member of a dynamic group having the 
appropriate authorization on an associated ACL. Otherwise, 
permission for the requested action is denied. 

FIG. 9 next illustrates another exemplary implementation 

60 of the invention in a content management system 220, i.e., 
to control the distribution of content to a user based upon the 
user's membership within a dynamic group. As shown in the 
figure, an LDAP hub directory 222 is populated with one or 
more group policies 224, representing the group configura- 

65 tion information described above, e.g., group membership 
criterion, domain selection criterion, distribution and syn- 
chronization rules, group ID, etc. 



04/06/2004, EAST Version: 1.4.1 



us 6,671,695 B2 

27 28 

In addition, user data 226 corresponding to one or more In addition, user data 266 corresponding to one or more 
users is entered into the LDAP directory to create one or users is entered into the LDAP directory to create one or 
more user records representative of users capable of being more user records representative of users capable of being 
authorized via content management. As shown in block 228, authorized via content management. As shown in block 268, 
one or more groups arc created based upon desired group 5 one or more groups arc created based upon desired group 
poUcies, and selected users are dynamically added to the policies, and selected users are dynamically added to the 
new groups based upon the membership criteria associated new groups based upon the membership criteria associated 
with the various new groups. The result of block 228 is the with the various new groups. The result of block 268 is the 
addition of new groups to the LDAP directory, now repre- addition of new groups to the LDAP directory, now repre- 
sented at 230. sented at 270. 

Next, as shown at block 232, the dynamic groups main- Next, as shown at block 272, the dynamic groups main- 
tained in directory 230 may be pushed to one or more spoke tained in directory 270 may be pushed to one or more spoke 
directories. In the alternative, direct lookups to the hub directories. In the alternative, direct lookups to the hub 
directory 230 may simply be supported, e.g., via remote directory 270 may simply be supported, e.g., via remote 
procedure calls or remote object invocations. procedure calls or remote object invocations. 

Also provided to the end-use directory 232 is a content Also provided is a software distribution management 
subscription process 234 that maps various content items to process 274 that stores mappings between software products 
various dynamic groups. Each mapping may also include the and groups. Each mapping may also include the specified 
specified permitted and restricted actions for the content. permitted and restricted actions for the software product. 
Thus, as shown in block 236, whenever an application needs The mappings are provided to an electronic software distri- 
to make a subscription check before pushing content to a 20 bution database 276, which is accessible by software distri- 
p articular user, the application accesses the content man- bution logic 278 that distributes software to individuals by 
agement system to determine whether the specified user is a resolving group memberships through directory group look- 
member of a dynamic group mapping to the specified ups via directory 272. 

content. If so, the content is distributed. Otherwise, distri- Yet another end-use application of dynamic groups is in 

bution is prohibited. 25 business-to-business groups. Through the aforementioned 

FIG. 10 next illustrates yet another exemplary implemen- distribution and synchronization functionality, multiple 

tation of the invention in an electronic messaging or group- users that span multiple enterprises may participate in 

ware system 240, i.e., to address messages to multiple users dynamic groups. Dynamic groups may therefore comprise 

based upon those users* membership within a dynamic extended bases of users, e.g., to link together various users 

group. As shown in the figure, an LDAP hub directory 242 30 such as buyers, purchasing agents, distributors, 

is populated with one or more group policies 244, repre- manufacturers, retailers, business partners, competitors, etc. 

senting the group configuration information described to facifitate different business processes, 

above, e.g., group membership criterion, domain selection Other end-use applications of dynamic groups will be 

criterion, distribution and synchronization rules, group ID, apparent to one of ordinary skill in the art having the benefit 

etc. 35 of the instant disclosure. Therefore, the invention is not 

In addition, user data 246 corresponding to one or more limited to the particular applications disclosed herein, 

users is entered into the LDAP directory to create one or wnRT<rTMr pyampt f 
more user records representative of users capable of being 

authorized via content management. As shown in block 248, One specific security management application of a 

one or more groups are created based upon desired group 40 dynamic group management system may be configured to 

policies, and selected users are dynamically added to the have the following functionality, and may be based upon the 

new groups based upon the membership criteria associated aforementioned architecture: 

with the various new groups. The result of block 248 is the 1- Directory services may have capability to generate and 

addition of new groups to the LDAP directory, now repre- maintain groups and group memberships based on user 

sented at 250. 45 attributes. 

Next, as shown at block 252, the dynamic groups main- 2. The groups and memberships may be propagated to 

tained in directory 250 may be pushed to one or more spoke 'domains' (Notes servers, NT servers, or other 'Spoke' 

or e-mail directories. In the alternative, direct lookups to the servers which must support LDAP) including develop- 

hub directory 250 may simply be supported, e.g., via remote ™ent and production environments, 

procedure calls or remote object invocations. so 3. May have ability to specify creation of Global or Local 

With the above -described directory structure, an e-mail group, 

tool 254 may select one or more groups and/or users from 4. May have capability to add one or many global groups to 

the directory for inclusion in an electronic message, in a ^ local group. 

manner generally known in the art. In addition, as shown at 5. Global group may be added to a local group by using 

254, the e-mail administrator may also configure the 55 "Global Group Name" as an attribute in group definition 

dynamic group management system to do direct LDAP criteria while creating/modifying a local group definition, 

lookups or have the dynamic groups pushed into the email 6. The following security classifications may apply to secu- 

dircctory. rity groups: 

FIG. 11 next illustrates another exemplary implcmcnta- 1- Group membership listings: 

tion of the invention in a software distribution system 260, 60 L OPEN: LLst group memberships for all users, 

i.e., to control the distribution of software to a user based 2. CLOSED: Only group owner, delegates can list 

upon the user's membership within a dynamic group. As group memberships for the groups they own. 

shown in the figure, an LDAP hub directory 262 is populated 2. Viewing group security definition: 

with one or more group policies 264, representing the group I. RULE-OPEN: All users can look at security group 

configuration information described above, e.g., group 65 definition. 

membership criterion, domain selection criterion, distribu- 2. RULE-CLOSED: Only group owners and delegates 

tion and synchronization rules, group ID, etc. can view group definition for any group. 
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7. Two types of groups may be supported: 

1. "AUTOMATIC* — Group memberships are automati- 
cally adjusted whenever there is any change in attribute 
types, attribute values and/or user attributes. 

2, "ONE-TIME"— Group definition criteria will be used ^ 
only to speed up generation of this group. Group 
definition criterion is no longer applicable to the group 
once the group is created. The group memberships 
cannot be altered from directory. (Adding and deleting 
specific users to and from automatically created secu- 
rity groups may be done via using "user name" as an 
attribute in the group definition criteria.) 

8. Groups and membership may be created and maintained 
via a scheduled batch process, or near real time. 

9. Groups may be left in the *hub' where they can be read 
directly, or they can be pushed to 'spoke' directories, 
which can exist anywhere (intranets, extrancts, WWW, 
inside other enterprises, etc.) 

10. Group memberships may always be same on all domains 
only with the exception of a non-existent user on a 
particular domain. 

11. May have abihty to modify group creation criteria and 
modifying criteria should result in altering group mem- 
berships through a modification process. 

12. The following synchronization functionality may be 
available for synchronizing groups and memberships, 
created from directory, across domains and directory 
databases: 

1. The Hub Directory may be the Master for synchroni- 
zation logic. 

2. For the groups in the directory the memberships on 
domains (target platforms like NT, Notes or 'spoke' 
directories supporting LDAP) may need to be synchro- 
nized with memberships in the Hub directory database. 35 
A report may need to be generated to highlight the 
membership mismatches if they occur. 

13. Groups that are in the directory and not on domains may 
need to be created on those appropriate domains, 

14. Groups may gel deleted in the directory only after they 40 
are deleted from all domaias. 

15. Security groups may not be effective dated. But attribute 
changes for effective dated attributes from an organization 
structure may automatically alter group definitions and 
group memberships. 45 

16. Group Definition Criteria: 

1. Group definition criteria may be based on one or more 
(any number) of user attributes. 

2. Only criteria used for group definition are "value of 
attribute IS" and or "value of attribute IS NOT". 50 

3. Group definition criteria may be a combination of 
multiple attributes with all "AND" or all "OR" condi- 
tions. 

4. All attributes and their values for defining criteria may 
be selected from predefined values. 

5. Effective dated group definition criteria. Other condi- 
tions such as ">", "<", "LIKE" etc. may be used. 

17. Creating Groups/Group Memberships: 

1. Only "Group Admins" may create a group. 

2. May need separate "Group Admin" privileges to create 
global/local groups. 

3. Partial success in creation of a group may be acceptable 
provided manual synchronization procedures are fol- 
lowed to salvage partially successful group creation 65 
scenarios. Partial success in group creation may be 
defined as (1) group is created at least on one domain 
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and in the directory database for all domain; and (2) 
Creation of complete memberships in directory. If 
memberships are not successfully created on all 
domains, then synchronization tool may get member- 
ships synchronized on different domains. 

4. Groups cannot be renamed. 

5. While creating group memberships, if a user does not 
exist on a particular domain, the user may not be a 
member of the group on that particular domain, but user 
will be a group member on the domains where he/she 
exists. 

6. Global groups may need to be created on all master NT 
and Notes domains. 

7. Global groups may be created only on NT master 
domains and can cause group creation on Notes 
domains. 

8. Local groups may be created only on NT Resource 
domains and can cause group creation on other 
domains. 

9. "Group Admins" can also specify that groups be pushed 
to 'spoke' directory servers. 

10. Where spoke servers exist, the InetOrgPerson Schema 
may be used as a mechanism for selecting users for 
inclusion in a group (manual or automatic). This 
implies that the Hub directory has read accesses to 
'spoke* directories, and may be managed as a manual 
work process. 

11. Where spoke servers exist, the GroupofNames Object 
Class may be used as the target for creating groups. 
This implies that the Hub directory has write accesses 
to 'spoke' directories, which may be managed as a 
manual work process. 

18. Modifying Groups/Group Memberships: 

1. Modifying group definition criteria may change group 
memberships accordingly. 

2. Delegates as well as group owners may modify group 
definition criteria for the groups they own. 

3. Modifying group definition criteria may generate audit 
log reflecting all the changes caused by changing the 
group definition criteria. 

4. Modifying or deleting an attribute value associated 
with a user may result in changing group membership 
during a batch transaction for that user. 

5. Changing global group definition criteria may generate 
a report of local groups affected by the change. This 
report and new rule for the global group definition may 
be communicated to group owners and delegates of the 
affected local group. 

6. Changing membership should do the changes in direc- 
tory database first and then on all the domains. If 
memberships are not successfully changed on all 
domains, then synchronization tool may gel member- 
ships synchronized on different domains. 

7. Once created, global group may not be changed to local 
group and vice versa. 

19. Deleting Groups/Group Memberships: 

1. Only group owners may delete groups they own. 

2. Groups may not be deleted from directory database 
until deleted from all domains. 

3. Deleting a global group may generate a report of local 
groups affected by the deletion. This report will may be 
communicated to group owners and delegates of the 
affected local groups. 

4. Deleting memberships may delete memberships in 
directory first and then on the domains. Synchroniza- 
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tion may be done in case of partial success in deleting 
memberships, 

20. Attribute Types and Attribute Values: 

1. "Attribute type owner" may own attribute types and the 
pick list values associated with the attribute types 
he/she owns. 

2. "Attribute type owner" may modify or delete attribute 
types and pick list values that he/she owns. 

3. HR may assign or remove HR-related attribute values 
associated with users. 

4. Attribute types and attribute values may be deleted even 
if they are assigned to a user. Group membership may 
be adjiLstable accordingly for the user via a batch 
process. 

5. Attribute types or attribute values may be deleted even 
if they are used in the group definition criteria. The 
group definition and group memberships for the groups 
using the deleted attribute type/value may then be 
altered. The group may not be deleted even if there does 
not exist any members in the group. Notification may 
need to be sent to owners and delegates of altered 
groups. 

6. From an HR perspective, security groups may be 
created for following criteria: 

1. Users working for one or more organizations. 

2. Scope (Global/Regional) 

3. Business Unit 

4. Function 

5. Region 

6. Role/Level 

7. Home organization of positions 

8. All users reporting directly to a position. 

9. All users reporting directly and indirectly to a 
position. 

10. Country 

11. OfiSce internal address 

12. Employment Status 

13. Employee/Contractor/EBP (external business 
partner) 

14. Sitecode 

21. Group Ownership/Delegates: 

1. There may always be one owner for every group. 

2. Ability to transfer ownership of a group. 

3. Only group owner and "Directory Admin" may transfer 
ownership of group. 

4. Ability to delegate group membership maintenance to 
other users or groups. 

5. Only group owner may add or remove delegates for the 
groups they own. 

6. Transferring group ownership may retain the delegates 
on the group. 

7. Delegates may not manage other delegates. 

22. Reporting (i.e., what information can be retrieved): 

1. List of groups a user belongs to. 

2. List of users in a group. 

3. List of groups owned by an owner. 

4. List of all users and roles for all administrative users. 

5. List of delegates for a group. 

6. List of all groups with their owners and delegates. 
Synchronization and Dynamic Updates 

The aforementioned exemplary security management 
application may include a Group Management Service 
(GMS) program and a Group Synchronizer Service 
(GSSYNC) program that cooperatively are used to dynami- 
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cally update dynamic groups consistent with the invention. 
The GMS program may be responsible for maintenance of 
groups, and may generally operate by reading command- 
requests in a Global Directory Services (GDS) database 

5 functioning as a hub directory, and acting upon the 
commands, making group changes against the hub directory. 
Such changes may then be pushed out, selectively, to spe- 
cific domains (e.g. Windows NT, Lotus Domino, ORACLE, 
or other LDAP directories functioning as spoke directories. 

10 Commands to the GMS program may be made by users 
via a thin-client (user-interface) component of the GDS 
system. Command-requests may be read, in turn, by GMS 
and transformed or deleted to acknowledge acceptance of 
the commands. The GMS may modify the groups and group 
membership on platforms (e.g., Notes and NT domains) as 
well as spoke directory servers, and record their states in the 
GDS database. For example, the status attributes discussed 
above in connection with FIG. 7 may be used to identify 
records to be operated upon by the GMS program, e.g., with 
a status of 0 when active and processed, and a status oO 
when some processing is required. 

The GMS program may be scheduled or near real-time, 
and may be implemented as a multi-threaded service that 
processes group changes and group memberships based on 
configurable parameters. 

The GSSYNC program may be configured as a process 
that operates in conjunction with the GMS program, but at 
a lower priority, running only run when the GMS program 
is not running. If the GSSYNC program is running when the 
GMS program begins execution, it may request that the 
GSSYNC program suspend or terminate itself to prevent 
potential group and membership conflicts between the two 
processes. 

A principal responsibility of the GSSYNC program may 
be to ensure that groups and their memberships are consis- 

35 tent with respect to the GDS database and the attendant 
domains. The GSSYNC program may be a configurable, 
multi-threaded service that processes an unlimited number 
of group and group membership changes per hour, by 
scaling that service through replication. 

40 GMS Program Functional Flow 

The following represents a conceptual view of the GMS 
logic. At the highest level, the GMS logic typically executes 
sequentially. However, for certain operations, the GMS 
program may spawn and synchronize multiple threads of 

45 execution to hasten adjustment of group membership lists. 
Additional worker threads may also be spawned to adjust 
group membership. 

The GMS program may be configured to execute the 
following steps each time it is scheduled to run: 

^° 1. Protect Against Synchronizer Conflict 

In general terms, the GMS program typically runs more 
frequently than the GSSYNC program, e.g,. once per hour 
vs. once per week. To prevent conflict, the GMS and 
GSSYNC programs are typically mutually exclusive, with 
the GMS program having higher priority. Thus, if the GMS 
program wishes to run but finds that the GSSYNC program 
is running, it should issue a request for the GSSYNC 
program to either suspend or shut down, and then retry the 
operation. In addition, this logic prevents multiple instances 

60 of the GMS program from executing simultaneously. 



[START] 

if CMS already tunning 

exit 
endif 
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-continued 



if GSSYNC running 

send GSSYNC request to suspend or shutdown 
goto SI AKV 

else 

set GSSYNC lock to prevent GSSYNC from running 
endif 



2. Delete Groups 

This section honors command requests for group deletion: 



34 



changed group memberships, based upon group definition 
criteria. 



for each attribute type to be deleted 

for each group that uses this attribute type 

del group defn attributes that match attributc_type_id 

next 

delete user attributes that match attribute_typc id 

delete attribute values that match attribute_type_id 
delete attribute delegates 
delete attribute types themselves 

next 



for each group to be deleted: 
del grp definition 
del grp members 
del grp delegates 
if local grp 

del grp hierarchy (global gips that may belong) 
endif 

for domains in which grp exists 20 

if grp global 

for any local grps possessing global grp 
del global group membership on domain 

endif 

del grp from domain 

del grp mapping for domain 25 
log delete/result code 

next 

if no errors 
del grp 

del gip hierarchy 
endif 3q 

next 



3. Remove Group from Domain 

This section honors command requests to remove a group 
from a domain, where a domain is a target platform (e.g. NT 35 
or Notes Domino, or a spoke directory based on LDAP or 
other technologies). This task applies to both global and 
local groups. 

40 



for each group to be removed 
del grp from domain 
del grp map for domain 
log result code 



6. Delete Attribute Values 

This section honors command requests to delete attribute 
values; note that removing an attribute value can result in 
changed group memberships, based upon group definition 
criteria. 



for each attribute value to be deleted 

for each group that uses this attribute value in its defn 
del group defn attr that match attribute_value id 

next 

del user attributes that match attribute typc_id 

reset default value for attributc_t>pc_id 

del attribute values that match attribute__typc„id 

next 



7. Delete User Attributes 

This section honors command requests to delete user 
attributes; note thai removing a user attribute can result in 
changed group memberships, based upon group definition 
criteria. 



for each user attribute to be deleted 

for each groi^ that references this attribute_type with 
this attribute value 
determine whether user is added or dropped from the group 

next 

delete gds_t_user_attributes for this user attribute 

next 



4. Delete Domains 

This section honors command requests to remove a 
domain from the system altogether. 



for each domain to be removed 

gel tu>l of grps mapped to that domain 
for each grp 

if grp global 

for any local grps possessing global gip 
del global group membership 

next 
endif 

del gip from domain 

del grp mapping for domain 

log delete/result code 

next 

next 



8. Calculating Deltas for Memberships 

The membership generation process is initiated by a set of 
50 'deltas* (or changes to the desired group membership). 
Members to be removed are signified by a group member- 
ship status value of 2; members to be added are denoted by 
a group membership status of 1. 

55 

for each group 

get list of current members 

get list of new members based upon group defn criteria 
discrepency-check : 
60 generate list of members to remove 

generate list of members to add 

next 



5. Delete Attribute Types 65 

'lliis section honors command requests to delete attribute 
types; note that removing an attribute type can result in 



9. Add a Group to a Domain 

This section honors requests to add a group to a domain. 
This task applies to both global and local groups. 
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for each group to be added 
create group on domain 
update group status 
get a membership list for this group 
populate membership in the domain 
if group is local 

get list of global groups contained in this group 

add global groups to domain 
end if 

next 



10 



10. Delete Global Groups from Ia)cal Groups 

Global groups may be permitted to be members of local 
groups (the converse is typically not true, however); it may 
be desirable to remove global groups from local groups, as 
follows. 



15 



For each global group to be added to a local group 
For the local group for this record 
For each domain 

Add global groups from domain 

Next 

Update gds_t_group_hierarchy record.slatus 

Next 

Next 



12. Adjust Membership on Domains or Spoke Servers 

This section honors the group membership 'deltas* (or 
change requests) as represented in the membership table. 
Firstly, necessary group memberships are deleted. Secondly, 
requested group membership additions are made. Multiple, 
separate threads can execute the addition and deletion 
requests; however, each thread typically must deal with an 
independent group. 
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GSSYNC program. In the remaining inactive time (between 
scheduled runs of the GMS program), the GSSYNC pro- 
gram is permitted to execute, honoring only active groups 
and memberships (status value set to 0). 
GSSYNC Program Functional Flow 

The following represents a generalized view of the 
GSSYNC logic. At the highest level, the GSSYNC logic 
may execute sequentially. However, for certain operations, 
GSSYNC program may be configured to spawn and syn- 
chronize multiple threads of execution to hasten adjustment 
of group membership lists. As needed, worker threads can be 
spawned to adjust group membership. 

The GSSYNC process may be configured to execute the 
following steps each time it is scheduled to run: 
1. Protect Against Synchronizer Conflict 

As above with the GMS program, the GSSYNC program 
is required to verify the GMS program is not currently 
running. 



For each global group to be deleted from a local group 
For the local group for this record 
For each domain 

Remove global group from domain 

Next 

Delete gds_t_group_hierarchy record 

Next 

Next 



11. Add Global Groups to Local Groups 

Addition of global groups to local groups occurs as 30 
follows. 



45 



[START] 

if GSSYNC already running 

exit 
cndif 

if GMS running 

exit 
cndif 



2. Validate Global Groups 

This section determines whether all GDS global groups 
actually exist on all master domains. If they arc not all 
present, GSSYNC program will create the groups on the 
appropriate domains. 



fetch list of global groups from GDS 
for each global group 

for each master domain 

if global group not present on domain 
create global group on domain 
record in GDS 
cndif 

next 

next 



3. Validate Local Groups 

This section determines whether all GDS local groups 
actually exist on the specified domains. If they are not all 
50 present, the GSSYNC program may create the local groups 
on the appropriate domains. 



For each group member to be deleted 
For the group, get list of domains 
For each domain 

Delete member from group 

Next 

Delete this group membership record 

Next 

For each group member to be added 
For the group, get list of domains 
For each domain 

Add member to group 

next 

Next 



14. Release Synchronizer Lock 

After executing the aforementioned sequence of 
operations, the GMS program may release its Mock* for 



55 fetch list of local groups from GDS 

for each local group 

for each domain registered for the local group 
if local group not present on domain 
create local group on domain 
record in GDS 

60 ."""^ 
next 

next 



4. Validate Global Group Membership 

111 is section synchronizes the membership of global 
groups based upon the membership lists maintained by the 
GDS. 
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For each global group 

get a list of members for the group from GDS (status o 0) 
for each master domain 

get members of group on domain 

next 

discrepancy-check and build list of adds/drops 
Cor all drop records 

drop on specified domain 

next 

for all add records 

add on specified domain 

next 



5. Validate Local Group Membership 

This section synchronizes the membership of local groups 
based upon the membership lists maintained by the GDS. 



For each local group 

get a list of members for the group from GDS (status - 0) 
get a list of global groups for the group from GDS (status - 0) 
for each domain 

get members of group on domain 

get global groups on domain 

next 

discrepancy check, build list of adds/drops 
for all drop records 

drop on specified domain 

next 

for all add records 

add on specified domain 
next 
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6. Release Synchronizer Lock 
After executing the sequence of operations, the GSSYNC 

program will release its 'lock' for CMS. 

7. Background Tasks 
Because it is of a lower priority, the GSSYNC program 

may execute a background thread that polls the GMS 
program synchronizer lock. If the GMS program synchro- 
nizcr lock is set (indicating that the GMS program is 
requesting that GSSYNC program terminate), the GSSYNC 
program may terminate itself after safely finishing iLs current 
operation. 

The GMS and GSSYNC modules may not be configured 45 
to talk to the domains or directory services database directly. 
Instead, they may share domain and GDS database services 
which reside in a separate API. The following API functions 
may be provided for shared use by the GMS and GSSYNC 
modules: 50 
General Services 

Initialize — initializes communications with GDS and 
domains 

Log_error — logs an error message 

Log—group change — logs a group change to the GDS group 
log table 

Log„member_change — logs a member change to the GDS 

member log table 
Terminate — terminates communication with GDS and 

domains 

High-Level Services ^0 
Group_ins — creates a group from any domain, records in 
GDS 

Group_del — deletes a group from any domain, records in 
GDS 

Member_ins — adds a member to a group, records in GDS 65 
Member_del — deletes a member from a group, records in 
GDS 



Group_list — lists groups present on any domain 
Member_list — lists members present on any domain 
GDS Access Services 

Ins — adds a new record to one of the GDS tables 
Upd — updates one or more records in GDS tables 
Del — deletes one or more records from the GDS tables 
SQL — retrieves information based upon a SQL query from 
GDS 

Notes Primitive Services (for Lotus Notes domains) 
NO_group_ins — adds a group to a Notes domain 
NO_group_del — deletes a group from a Notes domain 
NO_group_list — retrieves list of groups from Notes 
domain 

NO_member_ins — adds a member to a Notes domain 
-J 5 NO_member„del — deletes a member from a Notes domain 
NO_member_list — retrieves list of group members from 

Notes domain 
NT Primitive Services (for Windows NT domains) 
NT__group_jns — ^adds a group to an NT domain 
NT__group_del--<leletes a group from an NT domain 
NT__group_list — retrieves list of groups from NT domain 
NT_member_ins — adds a member to an NT domain 
NT_member__del — deletes a member from an NT domain 
NT__mcmbcr_list — retrieves list of group members from 

NT domain 
Spoke Primitive Services 

SPT_group__ins — adds a group to a spoke directory 
SPT_group„del — deletes a group from a spoke directory 
SPT_group_list — retrieves list of groups a spoke directory 
SPT_member_ins — adds a member to a spoke directory 
SPT_member_del — deletes a member from a spoke direc- 
tory 

SP r_member list — retrieves list of group members from a 

spoke directory 

Arguments for the API functions typically vary based 
upon domain and required functionality (e.g., NT group 
functions will take a BOOL flag indicating global/local 
group status). In addition, Notes functions will typically 
automatically compensate for canonical naming issues (e.g., 
adding a member via NO_member_ins will automatically 
add a short and a long — canonical — name to the member- 
ship list). 

Various modifications may be made to the illustrated 
emtxjdiments without departing from the spirit and scope of 
the invention. ITierefore, the invention lies in the claims 
hereinafter appended. 
What is claimed is: 
L An apparatus comprising: 

(a) a database within which is resident a dynamic group 
data structure, the dynamic group data structure includ- 
ing a group membership criterion and a set of member 
identifiers, each member identifier identifying a user 
from a plurality of users that meets the group mem- 
bership criterion; and 

(b) a program, coupled to the database, the program 
configured to dynamically update the dynamic group 
data structure by updating the set of member identifiers 
to include those of the plurality of users that currently 
meet the group membership criterion as of the dynamic 
update; 

wherein the program is configured to initially generate the 
dynamic group data structure by associating the group 
membership criterion with the dynamic group data 
structure, and by determining those of the pluraUty of 
users that meet the group membership criterion to 
initially associate the set of member identifiers with the 
group data structures: 
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wherein ihe program is further configured to generate the 
dynamic group data structure without user enumera- 
tions of any users to be associated with the dynamic 
group data structure. 

2. The apparatus of claim 1, wherein each user is asso- 5 
ciated with at least one characteristic, and wherein the group 
membership criterion selects users having a common char- 
acteristic. 

3. The apparatus of claim 2, wherein each of the plurality 
of users is associated with a user record, each user record 
including at least one attribute value for an attribute so as to 10 
represent a characteristic associated with the user associated 
with such user record, wherein each member identifier 
identifies the user record associated with its identified user, 
and wherein the group membership criterion identifies at 
least one attribute used to determine whether a user meets ^5 
the group membership criterion. 

4. The apparatus of claim 2, wherein the at least one 
characteristic associated with each user is selected from the 
group consisting of user skill, user job assignment, user 
specialty, user task, user role, user physical location, user 
organizational location, user network location, user domain, 
user interest, organization, company, work group, skills, 
roles, and combinations thereof. 

5. The apparatus of claim 1, further comprising a security 
program configured to access the dynamic group data struc- 
ture during authorization of a selected user from the plurality 25 
of users. 

6. The apparatus of claim 5, wherein the security program 
is configured to grant access to a resource when the selected 
user is authorized. 

7. 'ITie apparatus of claim 6, wherein the resource includes 30 
an electronically distributed computer program. 

8. The apparatus of claim 6, wherein the resource includes 
electronically distributed artistic content, 

9. The apparatus of claim 6, wherein the resource includes 

a network resource. 25 

10. The apparatus of claim 1, further comprising a second 
program configured to access the dynamic group data struc- 
ture when obtaining an electronic messaging address for a 
selected user from the plurality of users. 

11. The apparatus of claim 1, wherein each of the plurality 
of users is associated with a user record maintained a user 
database among a plurafity of distributed user databases. 

12. The apparatus of claim 11, wherein the plurality of 
distributed user databases are under the control of the same 
business enterprise, 

13. The apparatus of claim 11, wherein at least a portion 45 
of the plurality of distributed user databases are under the 
control of different btisiness enterprises. 

14. The apparatus of claim 11, wherein the program is 
configured to dynamically update the dynamic group data 
structure by initiating a query on each of the plurality of 50 
distributed user databases to retrieve member identifiers 
associated with users from each of the distributed user 
databases that match the group membership criterion, 

15. The apparatus of claim 11, further comprising a first 
computer configured to store the database, wherein the 
program is further configured to generate a mirrored group 
data structure including at least a subset of member identi- 
fiers from the set of member identifiers associated with the 
dynamic group data structure, and to distribute the mirrored 
group data structure to a second database in a second 
computer interfaced with the first computer. 

16. The apparatus of claim 15, wherein the mirrored group 
data structure includes the entire set of member identifiers. 

17. The apparatus of claim 15, wherein the mirrored group 
data structure includes only those member identifiers from 
the set of member identifiers that arc associated with the 65 
same business enterprise as that associated with the second 
computer. 



18. The apparatus of claim 15, wherein the program is 
further configured to synchronize the mirrored group data 
structure with the dynamic group data structure. 

19. The apparatus of claim 18, wherein the program is 
configured to synchronize the mirrored group data structure 
with the dynamic group data structure in response to an 
update to at least one of the dynamic group data structure 
and the mirrored group data structure. 

20. The apparatus of claim 15, wherein the first and 
second databases share a common database platform. 

21. 'ITie apparatus of claim 15, wherein the first and 
second databases are based on separate database platforms, 
and wherein the program is further configured to convert the 
mirrored group data structure to a format suitable for the 
database platform for the second database prior to distrib- 
uting the mirrored group data structure to the second data- 
base. 

22. The apparatus of claim 15, wherein the program is 
further configured to generate a second mirrored group data 
structure including at least a second subset of member 
identifiers from the set of member identifiers associated with 
the dynamic group data structure, and to distribute the 
second mirrored group data structure to a third database in 
a third computer interfaced with the first computer. 

23. The apparatus of claim 22, wherein the second and 
third databases are based on separate database platforms. 

24. The apparatus of claim 1, wherein the dynamic group 
data structure further has associated therewith a security 
policy that controls access to the dynamic group data 
structure. 

25. The apparatus of claim 24, wherein the security pohcy 
for the dynamic group data structure includes security rights 
associated with individual member identifiers from the set of 
member identifiers. 

26. The apparatus of claim 1, wherein the program is 
configured to dynamically update the dynamic group data 
structure in response to a modification to the group mem- 
bership criterion. 

27. A computer-implemented method of managing a 
group of members, the method comprising; 

(a) accessing a dynamic group data structure in a 
database, the dynamic group data structure including a 
group membership criterion and a set of member 
identifiers, each member identifier identifying a user 
from a plurality of users that meets the group mem- 
bership criterion; and 

(b) dynamically updating the dynamic group data struc- 
ture by updating the set of member identifiers to 
include those of the plurality of users that currently 
meet the group membership criterion as of the dynamic 
update; 

wherein the method is configured to initially generate the 
dynamic group data structure by associating the group 
membership criterion with the dynamic group data 
structure, and by determining those of the plurahty of 
users that meet the group membership criterion to 
initially associate the set of member identifiers with the 
group data structures; 

wherein the method is further configured to generate the 
dynamic group data structure without user enumera- 
tions of any users to be associated with the dynamic 
group data structure. 

28. A computer implemented method of creating a group 
of member users among a plurality of users, the method 
comprising: 

(a) associating with a dynamic group data structure a 
group membership criterion; 

(b) determining those of the plurality of users that meets 
the group membership criterion; (and) (c) associating 
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with the dynamic group data structure a set of member 
idenlLhers that identify those users that meet the group 
membership criterion; and 
(d) dynamically updating the dynamic group data struc- 
ture by updating the set of member identifiers to ^ 
include those of the plurality of users that currently 
meet the group membership criterion as of the dynamic 
update: 

wherein the method is configured to initially generate the 
dynamic group data structure by associating the group 
membership criterion with the dynamic group data 
structure, and by determining those of the plurality of 
users that meet the group membership criterion to 
initially associate the set of member identifiers with the 
group data structures; 

wherein the method is further configured to generate the 
dynamic group data structure without xiscr enumera- 
tions of any users to be associated with the dynamic 
group data structure. 

29. A program product, comprising: 

(a) a program configured to dynamically update the 
dynamic group data structure, which includes a group 
membership criterion and a set of member identifiers, 
each of which identifying a user from a plurality of 25 
users that meets the group membership criterion, the 
program configured to dynamically update the dynamic 
group data structure by updating the set of member 
identifiers to include those of the plurality of users that 
currently meet the group membership criterion as of the 3Q 
dynamic update; 

wherein the program is configured to initially generate the 
dynamic group data structure by associating the group 
membership criterion with the dynamic group data 
structure, and by determining those of the plurality of 35 
users that meet the group membership criterion to 
initially associate the set of member identifiers with the 
group data structures; 

wherein the program is further configured to generate the 
dynamic group data structure without user enumera- 
tions of any users to be associated with the dynamic 
group data structure; and 

(b) a signal bearing medium bearing the program. 

30. A data processing system, comprLsing: 

(a) a hub computer; 

(b) a plurality of target computer environments networked 
to the hub computer; 

(c) a database resident on the hub computer, the database 
including a dynamic group data structure, the dynamic 



45 



group data structure including a group membership 
criterion and a set of member identifiers, each member 
identifier identifying a user from a plurality of users 
that meets the group membership criterion; and 
(d) a program, coupled to the database, the program 
configured to generate a mirrored group data structure 
including at least a subset of member identifiers from 
the set of member identifiers associated with the 
dynamic group data structure, and to distribute the 
mirrored group data structure to a target computer 
environment from the plurality of target computer 
environments; 

wherein the program Ls configured to initially generate the 
dynamic group data structure by associating the group 
membership criterion with the dynamic group data 
structure, and by determining those of the plurality of 
users that meet the group membership criterion to 
initially associate the set of member identifiers with the 
group data structures; 

wherein the program is further configured to generate the 
dynamic group data structure without user enumera- 
tions of any users to be associated with the dynamic 
group data structure. 

31. The data processing system of claim 30, wherein the 
program is further configured to dynamically update the 
dynamic group data structure by updating the set of member 
identifiers to include those of the plurality of users that 
currently meet the group membership criterion as of the 
dynamic update. 

32. The data processing system of claim 30, wherein each 
of the plurality of users is associated with a user record 
maintained a user database among a plurality of distributed 
user databases, each user database resident in a target 
computer environment from the plurality of target computer 
environments. 

33. The data processing system of claim 32, wherein the 
plurality of target computer environments are under the 
control of the same business enterprise. 

34. The data processing system of claim 32, wherein at 
least a portion of the target computer environments are under 
the control of different business enterprises. 

35. The data processing system of claim 32, wherein the 
program is configured to dynamically update the dynamic 
group data stmcture by initiating a query on each of the 
plurality of distributed user databases to retrieve member 
identifiers associated with users from each of the distributed 
user databases that match the group membership criterion. 
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